Timing-oriented and architecture-centric system design using contracts

ABSTRACT

The method may include designing one or more software models for one or more software components to be included in an embedded system. The method may include collecting information from the one or more requirements, the one or more software components, and the one or more software models. The method may include generating one or more architecture models that describe an execution platform, physical constraints, non-functional constraints, and characteristics of the embedded system based on the collected information. The method may include determining timing semantics to be satisfied by execution of functions in the embedded system. The method may include generating, by an electronic device, contracts based on the one or more requirements, the one or more software components, the one or more software models, the one or more architecture models, and the timing semantics.

BACKGROUND

The specification relates to a timing-oriented and architecture-centricsystem design using contracts.

The design of embedded systems, including automotive systems usingconventional design approaches and programming methods may be difficult.In particular, these conventional design approaches and programmingmethods may be incapable of determining the correctness and performingverification of non-functional properties, such as timing-relatedproperties, for the embedded system.

In the last decade, the size of the embedded system has dramaticallyincreased. For example, an automotive embedded system may have more than100 engine control units and millions of lines of code. Attempts havebeen made to reduce the system complexity and a time to marketconstraint, by using a model-based design approach and early-phasevalidation technologies. These attempts have been widely adopted andpracticed in industry. However, system integration and its analysis,verification, and validation, even at the model level is still a bigchallenge due to the heterogeneity of the models and/or languages usedin the design and different semantics adopted to create the embeddedsystem.

Architecture design is also becoming a critical issue due to a largenumber of heterogeneous components in the system. An effectivearchitecture design has a great impact on cost, timing, performance,safety, reliability, etc.

Timing, with regard to a specific architecture, is another significantissue considered in designing an embedded system, particularly in theintegration phase. However, timing is hardly verified at thesystem-level.

SUMMARY

An embedded system may be generated based on requirements, prototypesthat include software components, virtual prototypes that includesoftware models, and formal specifications. The formal specificationseach include an architecture model, timing semantics, and a contract.

The architecture model may describe an executing platform includinghardware and software used by the software components and the softwaremodels, physical constraints, non-functional constraints, andcharacteristics of the embedded system. The architecture model and thetiming semantics may be generated based on information collected fromthe requirements, the software components, and the software models. Thearchitecture model may be generated using a modeling language or aformal language.

The timing semantics may be determined to be satisfied by execution offunctions that are correctly executed in the architectural model. Thetiming semantics may include synchronization and ordering of events,computing a time to execute the functions in the embedded system, anddelay that occurs when executing the functions and communication betweenthe functions. The architecture model may also include a behavior modeland the timing semantics may also be determined to be satisfied by thebehavior model.

The contracts may be generated based on the requirements, the softwarecomponents, the software models, the architecture model, and the timingsemantics. The contracts may specify expected properties of the softwarecomponents and the software models.

It may be determined whether the software components and the softwaremodels satisfy the contracts. For example, a static formal verificationor a run-time based verification may be performed. The formal languageor the modeling language used for the architecture model may be used todetermine whether the contracts are satisfied.

If the software components and the software models satisfy thecontracts, the models have been properly integrated. If the softwarecomponents and the software models fail to satisfy the contracts, thearchitecture models and the timing semantics are modified, modifiedcontracts are generated, and it may be determined whether the softwarecomponents and the software models satisfy the modified contracts. Thisprocess may repeat until the modified contracts are satisfied.

The subject matter described herein may provide numerous benefits. Forexample, the subject matter may reliably integrate models for thenext-generation model-based embedded systems design. The subject mattermay describe a seamless bridge between architecture modeling, timingsemantics, and contract-based composition of models. The subject mattermay also describe a framework for performing formal evaluation ofmodel-based system design, such as modeling checking, timing analysis,and architecture exploration. By applying these formal methods in theearly-design phase, there may be improvement and enhanced constructionin the embedded systems design, and a reduction of the overalldevelopment time.

According to one innovative aspect of the subject matter described inthis disclosure, a system and method for designing a large-scaleembedded system is described. The method may include designing one ormore software models for one or more software components to be includedin an embedded system, wherein the one or more software models describeone or more requirements for the one or more software components. Themethod may include collecting information from the one or morerequirements, the one or more software components, and the one or moresoftware models. The method may include generating one or morearchitecture model that describe an execution platform, physicalconstraints, non-functional constraints, and characteristics of theembedded system based on the collected information. The method mayinclude determining timing semantics to be satisfied by execution offunctions in the embedded system. The method may include integrating, byan electronic device, contracts based on the one or more requirements,the one or more software components, the one or more software models,the one or more architecture models, and the timing semantics. Themethod may include determining whether the one or more softwarecomponents and the one or more software models satisfy the contracts.

Other aspects include corresponding methods, systems, apparatus, andcomputer program products.

BRIEF DESCRIPTION OF THE DRAWINGS

The disclosure is illustrated by way of example, and not by way oflimitation in the figures of the accompanying drawings in which likereference numerals are used to refer to similar elements.

FIG. 1 is a block diagram illustrating an example device for designingan embedded system.

FIG. 2A is an example flowchart of a systematic method for designing anembedded system.

FIG. 2B is an example flowchart of the formal specification illustratedin FIG. 2A.

FIG. 2C is an example flowchart of an overall method for designing anembedded system.

FIG. 3 is a flowchart of an example method for designing an embeddedsystem.

FIG. 4 is a block diagram including an example system for designing anembedded system.

FIG. 5 is a flowchart of an example method for designing an advanceddriver assistance system.

DETAILED DESCRIPTION

FIG. 1 is a block diagram illustrating an example device 100 fordesigning an embedded system. The device 100 can be used by an originalequipment manufacturer (OEM) or a supplier as discussed in greaterdetail below with reference to FIG. 4. The device 100 may be, include,or be included in a server that a user accesses via a browser. In someimplementations, the device 100 may include physical hardware directlyaccessed by the user, such as a desktop computer, a mobile computer, alaptop, a smartphone, or any other computing device that includes amemory and a processor. Although the components are illustrated as beingpart of a single device 100, the components may be part of a distributedsystem.

The device 100 can include a design application 199, a processor 125, amemory 127, a display 129, and a communication unit 131. The componentsof the design device 100 are communicatively coupled by a bus 120.

The processor 125 includes an arithmetic logic unit, a microprocessor, ageneral-purpose controller, or some other processor array to performcomputations and provide electronic display signals to a display device.The processor 125 processes data signals and may include variouscomputing architectures including a complex instruction set computer(CISC) architecture, a reduced instruction set computer (RISC)architecture, a graphic processor unit (GPU) architecture or anarchitecture implementing a combination of instruction sets. AlthoughFIG. 1 includes a single processor 125, multiple processors 125 may beincluded. Other processors, operating systems, sensors, displays, andphysical configurations may be possible. The processor 125 is coupled tothe bus 120 for communication with the other components via signal line126.

The memory 127 stores instructions or data that may be executed by theprocessor 125. The instructions or data may include code for performingthe techniques described herein. The memory 127 may include a dynamicrandom access memory (DRAM) device, a static random access memory (SRAM)device, flash memory, or some other memory device. In someimplementations, the memory 127 also includes a non-volatile memory orsimilar permanent storage device and media including a hard disk drive,a floppy disk drive, a CD-ROM device, a DVD-ROM device, a DVD-RAMdevice, a DVD-RW device, a flash memory device, or some other massstorage device for storing information on a more permanent basis. Thememory 127 is coupled to the bus 120 for communication with the othercomponents via signal line 128.

As illustrated in FIG. 1, the memory 127 stores one or more ofrequirement data 191, software component data 193, software model data195, and formal specification data 197. The requirement data 191 mayinclude information about functional and non-functional requirements fora software component to perform. The requirements may be designed by aOEM, for example, using a formal language. The formal language mayinclude a standardized way of describing the software components and oneor more properties for the software components. The software componentdata 193 may include information about software components that satisfythe requirements described by the requirement data 191. The softwaremodel data 195 may include information about software models that arerepresentations of the software components that are used to buildvirtual prototypes. The formal specification data 197 may includeinformation about formal specifications that are used to integrate thesoftware models. The formal specifications may include architecturemodels, timing semantics, and contracts.

A formal specification may be used by the OEM to provide the supplierwith a framework of unambiguous interaction between the OEM and thesupplier. The supplier may choose to use their own model design forproduction. However, the one or more architectural models and the one ormore contracts included in the formal specification, describes thefunctional and non-functional requirements for the software componentsthat must be designed by the supplier (and, optionally, other suppliers)using the formal language. In this way, the formal specificationbeneficially ensures that the OEM and the suppliers have the sameunderstanding of how the embedded system and each software componentintegrated in the embedded system should be designed.

The display 129 can include hardware for displaying graphical data fromthe design application 199. For example, the display 129 rendersgraphics for displaying a user interface that displays information abouta virtual prototype. The display 129 is coupled to the bus 120 viasignal line 130.

The communication unit 131 can include hardware that transmits andreceives data to and from the device 100. The communication unit 131 iscoupled to the bus 120 via signal line 132. In some implementations, thecommunication unit 131 includes a port for direct physical connection toa network or to another communication channel. For example, thecommunication unit 131 includes a USB, SD, CAT-5, or similar port forwired communication with the device 100. In some implementations, thecommunication unit 131 includes a wireless transceiver for exchangingdata with the device 100 or other communication channels using one ormore wireless communication methods, including IEEE 802.11, IEEE 802.16,Bluetooth®, or another suitable wireless communication method.

In some implementations, the communication unit 131 includes a cellularcommunications transceiver for sending and receiving data over acellular communications network including via short messaging service(SMS), multimedia messaging service (MMS), hypertext transfer protocol(HTTP), direct data connection, WAP, e-mail, or another suitable type ofelectronic communication. In some implementations, the communicationunit 131 includes a wired port and a wireless transceiver. Thecommunication unit 131 also provides other conventional connections tothe network for distribution of files or median objects using standardnetwork protocols including TCP/IP, HTTP, HTTPS, and SMTP, etc.

The communication module 102 can include code and routines for handlingcommunications between the design application 199 and other componentsof the device 100. In some implementations, the communication module 102can include a set of instructions executable by the processor 125 toprovide the functionality described below for handling communicationsbetween the design application 199 and other components of the objectdetection device 100. In some implementations, the communication module102 can be stored in the memory 127 of the device 100 and can beaccessible and executable by the processor 125.

The design application 199 may include a communication module 102, adesign module 104, an architecture module 106, a timing module 108, ancontracts module 110, and a verification module 112. Other designapplication 199 components are possible. For example, the designapplication 199 may additionally include a user interface module thatgenerates graphical data that shows the progress of the design to auser. For example, the user interface module may generate a statusreport on the verification process.

The communication module 102 sends and receives data, via thecommunication unit 131, to and from the device 100. The communicationmodule 102 may also send and receive data between components of thedesign application 199. The communication module 102 may also send andreceive data between components of the design application 199 andcomponents of the device 100, such as between the design application 199and the display 129. The communication module 102 is coupled to the bus120 via signal line 103.

The design module 104 can include code and routines for designingsoftware models based on software components. In some implementations,the design module 104 can include a set of instructions executable bythe processor 125 to provide the functionality described below fordesigning software models based on software components. In someimplementations, the design module 104 can be stored in the memory 127of device 100 and can be accessible and executable by the processor 125.The design module 104 is coupled to the bus 120 via signal line 105.

The design module 104 may design software components based onrequirements. The requirements may be expressed in a formal language andspecified by a OEM. The design module 104 may design software modelsbased on the software components where the software models describerequirements for the software components.

Turning now to FIG. 2A, an example flowchart 200 of a systematic methodfor designing an embedded system is illustrated. FIG. 2A represents adirection of the flow of information during the design process. Thedesign process may be organized according to the following levels:requirements level 206, prototypes level 208, virtual prototypes level211, and formal specifications level 212. The requirements level 206includes a series of requirements 205 a, 205 b, and 205 c. Theprototypes level 208 includes software components 210 a, 210 b, and 210c. The virtual prototypes level 211 includes software models 215 a, 215b, and 215 c. The formal specifications stage 212 includes formalspecifications 220 a, 220 b, and 220 c.

Each discrete set of requirements 205 a, 205 b, 205 c providesrequirement data 191 to the software components 210 a, 210 b, 210 c,respectively, in the prototypes level 208. Each of the softwarecomponents 210 a, 210 b, 210 c, provides software component data 193 tothe software models 215 a, 215 b, 215 c, respectively, in the virtualprototypes level 211. The software models 215 a, 215 b, 215 c providessoftware model data 195 to different formal specifications 220 a, 220 b,220 c in the formal specification level 212.

The design module 104 may use the requirements data 191 to designsoftware components 210, and the software components 210 may be used todesign software models 215. As discussed in greater detail below, theformal specification level 212 includes formal specifications 220 thatinclude architecture models generated by the architecture module 106,timing semantics generated by the timing module 108, and contractsgenerated by the contract module 110.

The architecture module 106 can include code and routines for generatingan architecture model. In some implementations, the architecture module106 can include a set of instructions executable by the processor 125 toprovide the functionality described below for generating thearchitecture model. In some implementations, the architecture module 106can be stored in the memory 127 of device 100 and can be accessible andexecutable by the processor 125. The architecture module 106 is coupledto the bus 120 via signal line 107.

The architecture module 106 collects information from the requirements,the software components, and the software models. For example, thearchitecture module 106 may receive software model data 195 thatincludes the information from the requirements, the software components,and the software models. The architecture module 106 may provide thecollected information to the timing module 108, which uses the collectedinformation to determine timing semantics.

Turning to FIG. 2B, an example flowchart 250 of the formal specification220 from FIG. 2A is illustrated. The formal specification 220 includesarchitecture models 225 a, 225 b, and 225 c; timing semantics 230 a, 230b, 230 c; and contracts 235 a, 235 b, 235 c. The architecture models,the timing semantics, and the contracts are built based on thecorresponding software models 215 in a hierarchical manner. Thearchitecture module 106 generates the architecture model 225 a based onsoftware model data 195 from the software models 215 a, 215 b, 215 c.The timing semantics 230 are discussed in greater detail below withreference to the timing module 108. The contracts 235 are discussed ingreater detail below with reference to the contracts module 110.

The architecture module 106 may determine hardware and softwarearchitecture for software models 215 and software components 210 fromthe software model data 195. The architecture module 106 generates anarchitecture model that describes an execution platform, physicalconstraints, non-functional constraints, and characteristics of anembedded system based on the collected information. For example, anembedded system for a vehicle may include the following hardware andsoftware: electronic control units (ECUs), a bus, sensors, andactuators.

In some implementations, the architecture module 106 generates astandardized architecture model in an embedded system design thatincludes a modeling language or a formal language, such as architectureanalysis and design language (AADL), AUTomotive Open System Architecture(AUTOSAR), SYStem Modeling Language (SYSML), Modeling and Analysis ofReal-Time and Embedded systems (MARTE), etc.

In some implementations, the architecture module 106 develops behaviormodels to run on the architecture model. System properties includingtiming constraints, performance, and cost may be evaluated based on boththe behavior models and the architecture model.

The timing module 108 can include code and routines for determiningtiming semantics. In some implementations, the timing module 108 caninclude a set of instructions executable by the processor 125 to providethe functionality described below for determining timing semantics. Insome implementations, the timing module 108 can be stored in the memory127 of device 100 and can be accessible and executable by the processor125. The timing module 108 is coupled to the bus 120 via signal line109.

The timing module 108 may determine timing semantics to be satisfied byexecution of functions in the embedded system. For example, the timingmodule 108 may determine timing semantics based on the architecturemodel and the software models, along with the timing characteristics ofthe architecture model and the software models. In some implementations,timing semantics, including timing constraints, are defined on thebehavior model running on a specific architecture as formalized by thearchitecture model generated by the architecture module 106. The timingsemantics may include functions that are correctly executed.

The timing semantics may include the following properties of theembedded system: (1) synchronization and ordering of events as theabstraction results of data exchange among functions, softwarecomponents, etc.; (2) a computing time that describes a time needed forexecution of the functionality on the specific architecture; (3) a delaytime that describes a time needed for the execution of a specificfunctionality; and (4) other timing properties. In some implementations,the timing semantics does not include specific-execution related issues,such as scheduling, because the timing specification is incorporated asconstraints to be satisfied by all possible correct executions.

The timing semantics may be described using a standardized, formal, andmulticlock timing model. For example, the timing semantics may bedescribed using MARTE clock constraint specification language (CCSL) orAADL synchronous timing annex (ongoing).

The contracts module 110 can include code and routines for generatingcontracts. In some implementations, the contracts module 110 can includea set of instructions executable by the processor 125 to provide thefunctionality described below for generating contracts. In someimplementations, the contracts module 110 can be stored in the memory127 of device 100 and can be accessible and executable by the processor125. The contracts module 110 is coupled to the bus 120 via signal line111.

The contracts module 110 may generate contracts that indicateassumptions of preconditions (e.g., safety, performance, cost, etc.) andguarantees of post-conditions between software components 210 andsoftware models 215. The contracts module 110 may generate the contractsbased on the timing semantics. The contracts may be defined using formallanguages to enable the formation of the formal specification andverification of the contracts. For example, the contract can bespecified using common computational temporal logic, including lineartemporal logic (LTL), computational tree logic (CTL), or CTL*. Thecontracts may be particularly helpful for safety-critical embeddedsystems.

The contracts module 110 may generate contracts based on therequirements, the software components, the software models, and thearchitecture model. For example, the contracts module 110 may use thecontracts to determine the correctness and reliability of software model215 composition and integration.

The verification module 112 can include code and routines for analyzingthe contracts. In some implementations, the verification module 112 caninclude a set of instructions executable by the processor 125 to providethe functionality described below for analyzing the contracts. In someimplementations, the verification module 112 can be stored in the memory127 of device 100 and can be accessible and executable by the processor125. The verification module 112 is coupled to the bus 120 via signalline 113.

The verification module 112 may analyze the contracts to determinewhether the contracts are satisfied. The verification module 112 mayperform a static formal verification, such as model check verification,or a run-time based verification.

The verification module 112 is able to perform verification because therequirements 205, the architecture models 225, the timing semantics 230,and the contracts 235 are created using modeling languages or formallanguages. In some implementations, the verification module 112 analyzesthe requirements 205, the architecture models 225, and modelintegration. If the verification module 112 detects a problem, theverification module 112 may instruct the design module 104 to modify thesoftware components 210 or the software models 215, the architecturemodule 106 to modify the architecture models 225, or the timing module108 to modify the timing semantics 230. If the verification module 112does not detect a problem, the verification module 112 may determinethat the models can be used to build components for prototyping.

FIG. 2C is an example flowchart 275 of an overall method for designingan embedded system. In this example, the engineering process includes adesign phase 207 and a virtual prototyping phase 211. The formal virtualintegration 217 is a subset of the virtual prototyping phase 211 thatensures the correctness and reliability of the integration.

FIG. 3 is a flowchart of an example method 300 for designing an embeddedsystem, arranged according to some embodiments. The method may beperformed by a design application 199 stored on the device 100 ofFIG. 1. The device 100 may be a special-purpose computing deviceconfigured to provide some or all of the functionality described withreference to FIG. 3.

At block 302, one or more software models are designed for one or moresoftware components to be included in an embedded system. The one ormore software models may include one or more requirements for the one ormore software components. For example, the one or more software modelsmay describe one or more functional or non-functional requirements forthe one or more software components. The one or more software componentsmay be integrated to form an embedded system. The one or more softwaremodels may be described using a formal language. Optionally, the one ormore software models may be described using a modeling language.

At block 304, information is collected from the one or morerequirements, the one or more software components, and the one or moresoftware models. The information may include requirement data 191,software component data 193, and software model data 195 that is used tobuild the formal specification 220 of FIG. 2B, which includesarchitecture models 225, timing semantics 230, and contracts 235.

At block 306, one or more architecture models are generated thatdescribes an execution platform, physical constraints, non-functionalconstraints, and characteristics of an embedded system based on thecollected information. Behavior models may also be generated based onthe collected information to run on the one or more architecture models.

At block 308, timing semantics are determined to be satisfied byexecution of functions in the architectural model. The timing semanticsmay include timing constraints defined on the behavior model asformalized by the one or more architecture models.

At block 310, contracts are generated based on the one or morerequirements, the one or more software components, the one or moresoftware models, the one or more architecture models, and the timingsemantics. The contract may be described using a formal language. Thecontract may specify the expected properties of the software componentsand software models.

At block 312, the method 300 determines whether the one or more softwarecomponents and the one or more software models satisfy the contracts.Determining whether the one or more software components and the one ormore software models satisfy the contracts includes a formalverification method that may include determining whether each contractsatisfies the properties it promises to guarantee if the assumedpreconditions included in the contract exist. In this way, the one ormore contracts are a reflection of the requirements on the one or moremodels. This verification step may include static formal verification,such as model check verification, or run-time based verification.

If the one or more software components and the one or more softwaremodels fail to satisfy the contract, at block 314 at least one of theone or more software components, the one or more software models, one ormore architectural models, and the timing semantics are modified,modified contracts are generated, and the method 300 determines whetherthe one or more software components and the one or more software modelssatisfy the modified contracts. If the method 300 determines that theone or more software components and the one or more software modelssatisfy the modified contracts, the method 300 ends. If the method 300determines that the one or more software components and the one or moresoftware models fail to satisfy the modified contracts, then the method300 returns to block 302. Optionally, the method 300 may be configuredso that steps 314, and 302-312 are repeated until the one or moresoftware components and the one or more software models satisfy themodified contracts.

FIG. 4 is a block diagram including an example system 400 for designingan embedded system. The system 400 includes an OEM 410, a supplier 420,and a client device 403. The OEM 410 may access a design application 199a. For example, the OEM 410 may use the design application 199 a togenerate software components 210 and software models 215. The OEM 410may share the software components 210, the software models 215, andformal specifications 220 that includes contracts 235 that describe thefunctional and non-functional requirements for the software components210 that must be designed by the supplier (and, optionally, othersuppliers) using the formal language.

The supplier 420 may include a design application 199 b that receivesthe software components 210, the software models 215, and formalspecifications 220. The supplier 420 may use the design application 199b to create software components 210 according to the formalspecifications 220.

The OEM 410 and the supplier 420 may communicate via a network 405. TheOEM 410 may access the network 405 via signal line 411. The supplier 420may access the network 405 via signal line 421.

The network 405 can include a conventional type, wired or wireless, andmay have numerous different configurations including a starconfiguration, token ring configuration, or other configurations.Furthermore, the network 405 may include a local area network (LAN), awide area network (WAN) (e.g., the Internet), or other interconnecteddata paths across which multiple devices may communicate. In someimplementations, the network 405 may be a peer-to-peer network. Thenetwork 405 may also be coupled to or include portions of atelecommunications network for sending data in a variety of differentcommunication protocols. In some implementations, the network 405includes Bluetooth® communication networks or a cellular communicationsnetwork for sending and receiving data including via short messagingservice (SMS), multimedia messaging service (MMS), hypertext transferprotocol (HTTP), direct data connection, WAP, e-mail, etc. In someimplementations, the network 405 may include a global positioning system(GPS) satellite. The network 405 may be a mobile data network, forexample, 3G, 4G, LTE, Voice-over-LTE (“VoLTE”), or any other mobile datanetwork or combination of mobile data networks. In some implementations,the network 405 may be a combination of different networks.

The OEM 410 may receive software components 210 from the supplier 420.For example, the supplier 420 may transmit the software components 210via the network 405 or the supplier 420 may physically provide thesoftware components 210, such as by providing the OEM with softwarecomponents 210 on a tangible computer-readable medium. The OEM 410 mayreceive software components 210 from multiple suppliers 420.

The OEM 410 may generate an embedded system 404. The embedded system 404may be used in a client device 403, such as the vehicle illustrated inFIG. 4. The embedded system 404 may be used in vehicles, for example, toprovide infotainment, enable wireless connectivity to the network,maximize efficiency, reduce pollution, to implement anti-lock brakingsystems, for electronic stability control, automatic four-wheel drive,and for an advanced driver assistance system.

FIG. 5 is a flowchart of an example method 500 for designing an advanceddriver assistance system (ADAS). Specifically, the ADAS system mayinclude an embedded system for adaptive cruise control. The method 500may be implemented using the system 400 illustrated in FIG. 4. Therequirements stage may include requirements for detecting objects infront of a vehicle including other vehicles directly in front of thevehicle and other vehicles in adjacent lanes. The prototyping stage mayinclude designing software components based on requirements for the ADASsystem. For example, the software components may be designed forhardware involved in the ADAS system, such as for sensors that detectobjects in the road and determine a distance between the client device403 and the objects. The hardware may also include hardware or softwarefor transmitting instructions between different software components. Thehardware may also include hardware configured to apply a brake to theclient device 403 and hardware to modify the settings for the cruisecontrol. The virtual prototyping stage may include designing softwaremodels that include the software components and how the differentsoftware components interact in the embedded system.

The formal specification includes architecture models, timing semantics,and contracts. The architecture models describe an execution platform,physical constraints, non-functional constraints, and characteristics ofthe embedded system. The timing semantics describe timing constraints tobe satisfied by the execution of functions in the architectural model.In this example, the timing semantics are determined based on a clockcalculus. The contracts include assumptions of preconditions andguarantees of post-conditions between the software components and thesoftware models.

The method 500 determines whether the software components and thesoftware models satisfy the contracts by performing a formal evaluationof the contracts, the timing semantics, and the architecture. The method500 also analyzes the virtual integration and the component integrationto determine whether the software components and the software modelssatisfy the contracts.

In the above description, for purposes of explanation, numerous specificdetails are set forth in order to provide a thorough understanding ofthe specification. It will be apparent, however, to one skilled in theart that the disclosure can be practiced without these specific details.In some instances, structures and devices are shown in block diagramform in order to avoid obscuring the description. For example, theimplementations can be described above primarily with reference to userinterfaces and particular hardware. However, the implementations canapply to any type of computing device that can receive data andcommands, and any peripheral devices providing services.

Reference in the specification to “some implementations” or “someinstances” means that a particular feature, structure, or characteristicdescribed in connection with the implementations or instances can beincluded in at least one implementation of the description. Theappearances of the phrase “in some implementations” in various places inthe specification are not necessarily all referring to the sameimplementations.

Some portions of the detailed descriptions that follow are presented interms of algorithms and symbolic representations of operations on databits within a computer memory. These algorithmic descriptions andrepresentations are the means used by those skilled in the dataprocessing arts to most effectively convey the substance of their workto others skilled in the art. An algorithm is here, and generally,conceived to be a self-consistent sequence of steps leading to a desiredresult. The steps are those requiring physical manipulations of physicalquantities. Usually, though not necessarily, these quantities take theform of electrical or magnetic signals capable of being stored,transferred, combined, compared, and otherwise manipulated. It hasproven convenient at times, principally for reasons of common usage, torefer to these signals as bits, values, elements, symbols, characters,terms, numbers, or the like.

It should be borne in mind, however, that all of these and similar termsare to be associated with the appropriate physical quantities and aremerely convenient labels applied to these quantities. Unlessspecifically stated otherwise as apparent from the following discussion,it is appreciated that throughout the description, discussions utilizingterms including “processing” or “computing” or “calculating” or“determining” or “displaying” or the like, refer to the action andprocesses of a computer system, or similar electronic computing device,that manipulates and transforms data represented as physical(electronic) quantities within the computer system's registers andmemories into other data similarly represented as physical quantitieswithin the computer system memories or registers or other suchinformation storage, transmission, or display devices.

The implementations of the specification can also relate to a processorfor performing one or more steps of the methods described above. Theprocessor may be a special-purpose processor selectively activated orreconfigured by a computer program stored in the computer. Such acomputer program may be stored in a computer-readable storage medium,including, but is not limited to, any type of disk including floppydisks, optical disks, CD-ROMs, and magnetic disks, read-only memories(ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic oroptical cards, flash memories including USB keys with non-volatilememory, or any type of media suitable for storing electronicinstructions, each coupled to a computer system bus.

The specification can take the form of some entirely hardwareimplementations, some entirely software implementations or someimplementations containing both hardware and software elements. In somepreferred implementations, the specification is implemented in software,which includes, but is not limited to, firmware, resident software,microcode, etc.

Furthermore, the description can take the form of a computer programproduct accessible from a computer-usable or computer-readable mediumproviding program code for use by or in connection with a computer orany instruction execution system. For the purposes of this description,a computer-usable or computer-readable medium can be any apparatus thatcan contain, store, communicate, propagate, or transport the program foruse by or in connection with the instruction execution system,apparatus, or device.

A data processing system suitable for storing or executing program codewill include at least one processor coupled directly or indirectly tomemory elements through a system bus. The memory elements can includelocal memory employed during actual execution of the program code, bulkstorage, and cache memories which provide temporary storage of at leastsome program code in order to reduce the number of times code must beretrieved from bulk storage during execution.

Input/output or I/O devices (including, but not limited, to keyboards,displays, pointing devices, etc.) can be coupled to the system eitherdirectly or through intervening I/O controllers.

Network adapters may also be coupled to the system to enable the dataprocessing system to become coupled to other data processing systems orremote printers or storage devices through intervening private or publicnetworks. Modems, cable modem, and Ethernet cards are just a few of thecurrently available types of network adapters.

Finally, the algorithms and displays presented herein are not inherentlyrelated to any particular computer or other apparatus. Variousgeneral-purpose systems may be used with programs in accordance with theteachings herein, or it may prove convenient to construct morespecialized apparatus to perform the required method steps. The requiredstructure for a variety of these systems will appear from thedescription below. In addition, the specification is not described withreference to any particular programming language. It will be appreciatedthat a variety of programming languages may be used to implement theteachings of the specification as described herein.

The foregoing description of the implementations of the specificationhas been presented for the purposes of illustration and description. Itis not intended to be exhaustive or to limit the specification to theprecise form disclosed. Many modifications and variations are possiblein light of the above teaching. It is intended that the scope of thedisclosure be limited not by this detailed description, but rather bythe claims of this application. As will be understood by those familiarwith the art, the specification may be embodied in other specific formswithout departing from the spirit or essential characteristics thereof.Likewise, the particular naming and division of the modules, routines,features, attributes, methodologies, and other aspects are not mandatoryor significant, and the mechanisms that implement the specification orits features may have different names, divisions, or formats.Furthermore, as will be apparent to one of ordinary skill in therelevant art, the modules, routines, features, attributes,methodologies, and other aspects of the disclosure can be implemented assoftware, hardware, firmware, or any combination of the three. Also,wherever a component, an example of which is a module, of thespecification is implemented as software, the component can beimplemented as a standalone program, as part of a larger program, as aplurality of separate programs, as a statically or dynamically linkedlibrary, as a kernel-loadable module, as a device driver, or in everyand any other way known now or in the future to those of ordinary skillin the art of computer programming. Additionally, the disclosure is inno way limited to implementation in any specific programming language,or for any specific operating system or environment. Accordingly, thedisclosure is intended to be illustrative, but not limiting, of thescope of the specification, which is set forth in the following claims.

What is claimed is:
 1. A method of designing a large-scale embeddedsystem for an original equipment manufacturer, the method comprising:designing one or more software models for one or more softwarecomponents to be included in an advanced driver assistance system of avehicle that includes an embedded system, wherein the one or moresoftware models describe one or more requirements for detecting objectsat least substantially in front of the vehicle and the one or moresoftware components are associated with operation of hardware that iscontrollable by the advanced driver assistance system; collectinginformation from the one or more requirements for detecting the objectsat least substantially in front of the vehicle, the one or more softwarecomponents that are associated with operation of the hardware, and theone or more software models; generating one or more architecture modelsthat describe an execution platform, physical constraints,non-functional constraints, and characteristics of the embedded systembased on the collected information; determining timing semantics to besatisfied by execution of functions in the embedded system based onordering of events; generating, by an electronic device, initialcontracts based on the one or more requirements, the one or moresoftware components, the one or more software models, the one or morearchitecture models, and the timing semantics; determining, by theelectronic device, whether the one or more software components and theone or more software models satisfy the initial contracts; responsive tothe initial contracts failing to be satisfied, modifying at least one ofthe one or more software components, the one or more software models,the one or more architecture models, and the timing semantics;generating modified contracts based on modifying at least one of the oneor more software components, the one or more software models, the one ormore architecture models, and the timing semantics; and determining thatthe one or more software components and the one or more software modelssatisfy the modified contracts.
 2. The method of claim 1, whereindetermining, by the electronic device, whether the one or more softwarecomponents and the one or more software models satisfy the initialcontracts is based on a run-time based verification.
 3. The method ofclaim 1, wherein determining timing semantics to be satisfied byexecutions of functions in the embedded system includes functions thatare correctly executed.
 4. The method of claim 1, wherein determiningtiming semantics to be satisfied by executions of functions in theembedded system is further based on synchronization of events, computinga time to execute the functions in the embedded system, and delay thatoccurs when executing the functions and communication between thefunctions.
 5. The method of claim 1, wherein determining whether the oneor more software components and the one or more software models satisfythe initial contracts includes performing a static formal verification.6. The method of claim 1, wherein the initial contracts indicateassumptions of preconditions that include safety, performance, and cost,and guarantees of post-conditions between the software components andthe software models.
 7. The method of claim 1, further comprisingdeveloping one or more behavior models to run on the one or morearchitecture models and wherein determining timing semantics includestiming semantics to be satisfied by the one or more behavior models. 8.The method of claim 1, wherein the initial contracts specify expectedproperties of the one or more software components and the one or moresoftware models.
 9. The method of claim 1, wherein the one or morearchitecture models are generated using a modeling language or a formallanguage, and wherein the modeling language or the formal language isused to determine whether the initial contracts are satisfied based onthe one or more requirements, the one or more software components, theone or more software models, the one or more architecture models, andthe timing semantics.
 10. The method of claim 1, wherein the advanceddriver assistance system is a system for adaptive cruise control.
 11. Anon-transitory computer-readable medium for designing a large-scaleembedded system, the non-transitory computer-readable medium havingcomputer instructions stored thereon that are executable by a processingdevice to perform or control performance of steps comprising: designingone or more software models for one or more software components to beincluded in an advanced driver assistance system of a vehicle thatincludes an embedded system, wherein the one or more software modelsdescribe one or more requirements for detecting objects at leastsubstantially in front of the vehicle and the one or more softwarecomponents are associated with operation of hardware that iscontrollable by the advanced driver assistance system; collectinginformation from the one or more requirements for detecting the objectsat least substantially in front of the vehicle, the one or more softwarecomponents that are associated with operation of the hardware, and theone or more software models; generating one or more architecture modelsthat describe an execution platform, physical constraints,non-functional constraints, and characteristics of the embedded systembased on the collected information; determining timing semantics to besatisfied by execution of functions in the embedded system based onordering of events; generating initial contracts based on the one ormore requirements, the one or more software components, the one or moresoftware models, the one or more architecture models, and the timingsemantics; determining whether the one or more software components andthe one or more software models satisfy the initial contracts;responsive to the initial contracts failing to be satisfied, modifyingat least one of the one or more software components, the one or moresoftware models, the one or more architecture models, and the timingsemantics; generating modified contracts based on modifying at least oneof the one or more software components, the one or more software models,the one or more architecture models, and the timing semantics; anddetermining that the one or more software components and the one or moresoftware models satisfy the modified contracts.
 12. The non-transitorycomputer-readable medium of claim 11, wherein determining whether theone or more software components and the one or more software modelssatisfy the initial contracts is based on a run-time based verification.13. The non-transitory computer-readable medium of claim 11, whereindetermining timing semantics to be satisfied by executions of functionsin the embedded system includes functions that are correctly executed.14. The non-transitory computer-readable medium of claim 11, whereindetermining timing semantics to be satisfied by executions of functionsin the embedded system is further based on synchronization of events,computing a time to execute the functions in the embedded system, anddelay that occurs when executing the functions and communication betweenthe functions.
 15. The non-transitory computer-readable medium of claim11, wherein determining whether the one or more software components andthe one or more software models satisfy the initial contracts includesperforming a static formal verification.
 16. The non-transitorycomputer-readable medium of claim 11, wherein the initial contractsindicate assumptions of preconditions that include safety, performance,and cost, and guarantees of post-conditions between the softwarecomponents and the software models.
 17. The non-transitorycomputer-readable medium of claim 11, wherein the steps further comprisedeveloping one or more behavior models to run on the one or morearchitecture models and wherein determining timing semantics includestiming semantics to be satisfied by the one or more behavior models. 18.The non-transitory computer-readable medium of claim 11, wherein theinitial contracts specify expected properties of the one or moresoftware components and the one or more software models.
 19. Thenon-transitory computer-readable medium of claim 11, wherein the one ormore architecture models are generated using a modeling language or aformal language, and wherein the modeling language or the formallanguage is used to determine whether the initial contracts aresatisfied based on the one or more requirements, the one or moresoftware components, the one or more software models, the one or morearchitecture models, and the timing semantics.
 20. A method of designinga large-scale embedded system for an original equipment manufacturer,the method comprising: designing one or more software models for one ormore software components to be included in an advanced driver assistancesystem of a vehicle that includes an embedded system, wherein the one ormore software models describe one or more requirements for detectingobjects at least substantially in front of the vehicle and the one ormore software components are associated with operation of hardware thatis controllable by the advanced driver assistance system; collectinginformation from the one or more requirements for detecting the objectsat least substantially in front of the vehicle, the one or more softwarecomponents that are associated with operation of the hardware, and theone or more software models; generating one or more architecture modelsthat describe an execution platform, physical constraints,non-functional constraints, and characteristics of the embedded systembased on the collected information; determining timing semantics to besatisfied by execution of functions in the embedded system based onsynchronization and ordering of events, computing a time to execute thefunctions in the embedded system, and delay that occurs when executingthe functions, wherein the timing semantics are based on a multiclocktiming model; generating, by an electronic device, initial contractsbased on the one or more requirements, the one or more softwarecomponents, the one or more software models, the one or morearchitecture models, and the timing semantics; determining, by theelectronic device, whether the one or more software components and theone or more software models satisfy the initial contracts; responsive tothe contracts failing to be satisfied, modifying the one or moresoftware components, the one or more software models, the one or morearchitecture models and the timing semantics; generating modifiedcontracts; and determining whether the one or more software componentsand the one or more software models satisfy the modified contracts.